Add SolrCloud update consistency documentation - #4716
Conversation
- New ref guide page solrcloud-update-consistency.adoc stating the consistency model of /update in SolrCloud: acknowledgment semantics, durability, ordering, atomicity, visibility, optimistic concurrency, retry-ability, and leader failover - New dev-docs/distributed-update-internals.adoc: implementation deep-dive of the distributed update path (routing, fan-out, acknowledgment and error handling, shard terms) and versioning/optimistic concurrency, with an eye toward reasoning about idempotency and retries - AGENTS.md: add a Developer Docs Index so coding agents discover dev-docs/ when working on related topics Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>
|
|
||
| Internals: | ||
|
|
||
| - `dev-docs/overseer/overseer.adoc` — Overseer: cluster state updates, ZkStateWriter, collection API message flow |
There was a problem hiding this comment.
This new section looks very useful for agents, like a "map" of where to read more on dev topics. I like it.
|
|
||
| Developers interested in how these guarantees are implemented should read the companion document https://github.com/apache/solr/blob/main/dev-docs/distributed-update-internals.adoc[Distributed Update Internals] in the source repository. | ||
|
|
||
| == What a Successful Update Means |
There was a problem hiding this comment.
"Replication" might be a better heading for the content
| There is no ordering guarantee *across different documents*. | ||
| Documents sent in one batch may be applied on replicas, and become searchable, in a different order than submitted — especially across shards. | ||
|
|
||
| == Atomicity |
There was a problem hiding this comment.
Needs more wording around nested documents. And maybe for in-place updates.
Should reference the TolerantUpdateProcessor.
Should reference the rollback command.
|
|
||
| == Visibility | ||
|
|
||
| An update is not searchable until a commit opens a new searcher; durability (via the transaction log and hard commits) and searchability are independent. |
There was a problem hiding this comment.
Would be worth a note on routing requests by the same user/client to the same replica to combat strange visibility issues.
|
|
||
| The exception is xref:configuration-guide:realtime-get.adoc[RealTime Get], which retrieves the latest version of a document by id — including uncommitted updates — directly from the transaction log. | ||
|
|
||
| == Optimistic Concurrency |
There was a problem hiding this comment.
should reference DocBasedVersionConstraintsProcessor
|
|
||
| C->>N: /update (batch of docs) | ||
| N->>L: forward each doc (DistribPhase=TOLEADER) | ||
| L->>L: per-doc lock; OCC check; assign _version_ |
There was a problem hiding this comment.
this diagram isn't being rendered by GitHub. And IntelliJ complained on this line " or ID expected, got ';'" (GitHub complained likewise)
I want more documentation about Solr's consistency model and on how Solr implements it. So I had Claude Fable work on producing this. Ultimately I want to discuss atomicity / idempotency... that's either a follow-on conversation or could very well happen here.
The first commit here is submitted with zero a-priori review; I will review it momentarily here and hopefully others will to.